Deferred sychronization of distributed objects

ABSTRACT

A method and apparatus is disclosed for data communication between agents, such as those in an electronic conferencing system. In an electronic conferencing a system wherein data is shared between a plurality of participants during an electronic conference users, a method is disclosed for maintaining consistency of the data among the participants during the electronic conference users. The method of the present invention comprises the following steps: a) each participant in the electronic conferencing system user maintains a local copy of the shared data for the electronic conference during the electronic conference ; b) one of the participants users commences to perform modifications to an associated local copy of the shared data; c) subsequent to the step of commencing modifications, a participant user requests an index for the modifications from an arbitrator participant user, wherein the modifications to the associated local copy of the shared data may continue to be performed; d) the arbitrator participant user responds to the participant user requesting the index for the modifications; and e) a participant user modifies the associated local copy of the shared data according to the index received from the arbitrator participant user and transfers the local modifications to remote participants users. In one embodiment, the users are participants of an electronic conference, and the shared data are the “meeting” data of the electronic conference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is related to teleconferencing computer systems.More specifically, the present invention is related to mechanisms forcommunicating data among a plurality of users, e.g. participants in anelectronic conferencing system.

2. Background Information

One of the more developing areas of computer networking is the field ofelectronic conferencing. Conferencing provides the ability to have anelectronic on-line “meeting” between a plurality of users on computersystems in a variety of locations. Users at a variety of sites maycommunicate with one another as if they were in the same room. Usingsuch application programs, modern communication systems have enabled theability to have a meeting wherein all users participate in the meetingthrough their individual computer systems and share data, graphics, textand other types of information. Users may communicate with one anothersharing data in the form of graphical images, text or other annotationsand other information represented on the computer system display. Thisis analogous to a meeting where participants in a face-to-face meetingmay display information to one another on a white or blackboard andother participants may add annotations, delete or otherwise modify theboard. It is also anticipated that as bandwidth of communication mediaimproves and compression standards for graphical data also become morerobust that video data may also be shared among a plurality of connectedusers during such teleconferences.

One of the requisites of an electronic conferencing system is the needto replicate the same data on all users' displays participating in theconference. Such systems typically implement this capability in avariety of ways. The most common is the client/server model wherein asingle connected node acts as a “server” of other nodes in the systemand the remaining nodes connected in the conference act as slaves orclients to the server process. Thus, each of the clients merely receivedata from the central machine to update their displays. Such systems,however, are entirely dependent upon the service being provided by theserver and the throughput of the communication medium. Obviously,systems wherein the clients merely act as displays and inputs for userrequests suffer from severe performance problems due to resultingupdates of data from the server, which is typically handled serially bythe server.

Another prior art solution for maintaining all of a participant'sdisplay in a conferencing system synchronous rely on a distributedclient/server system. In a distributed client/ server approach a sharedobject structure is kept on the server and clients are made aware ofchanges of that distributed information through alerts or demonsdaemons. The disadvantage of this approach, similar to the centralizedclient/server approach is the reliance on the architecture itself. Thisincludes a data conferencing application which must be able to connectseveral users over a phone line from point to point without requiringaccess to a centralized common server.

In the client/server approach, moreover, performance suffers greatlybecause requests to add or delete objects such as annotations, graphicalimages or other information on a participant's display is entirelydependent upon communication from the server. Thus, real-timeperformance severely suffers in prior art client/server models sinceapproval to act and manipulate upon objects on a participant's displayis entirely dependent upon a whole set of dependent variables such asthe number of requests to the server pending, the throughput of thecommunication medium, the number of participants connected, etc.

Yet another prior art approach for maintaining synchronicity of aplurality of participants in a conferencing system is the use of adistributed object-oriented system. This is a generalized approach whichrelies upon extensions, in one prior art solution, of the SmallTalklanguage itself. In this prior art system, “local” objects send messagesto “proxy” objects which are local representatives for objects in the“shared” object space. The proxy objects communicate with the realobjects through an RPC (Remote Procedure Call) mechanism. RPC is aprotocol governing the method with which an application activatesprocesses on other nodes and retrieves the results. Such a conventionalmechanism is defined by Sun Microsystems, Inc. and described in RFC-1057that provides a standard for initiating and controlling processes onremote or distributed computer systems.

The problem with this approach is in its generality which requiresextensive support for sharing any object while making no assumptionsabout the behavior of objects. This has two disadvantages. First, acomplex “SmallTalk system” is needed to support the distribution ofobjects in general. Second, the concurrency problem for any object isdifficult because multiple participants may have different objects intheir systems and such different objects may not be ale able to becommunicated to the remaining users.

Yet another of the disadvantages of prior art data conferencing systemsis their ability to support the transfer of very large blocks ofinformation. Typically, such systems have relied upon point-to-pointcommunication schemes wherein individual nodes such as the server, inthe client/server model, must transmit the information from oneindividual node to the server and then from the server to the remainingparticipants' systems. Also, the transfer of very large pieces of data,such as files and/or images or other data, consumes lots of resources inthe system and bandwidth of the communication medium. Thus, prior artconferencing systems suffer from severe performance penalties caused bythe amount of data which may be transmitted within the system during ateleconference.

Thus, prior art distributed data conferencing processing systems sufferfrom many disadvantages.

SUMMARY AND OBJECTS OF THE PRESENT INVENTION

The present invention relates to methods and apparatus for communicationdata between agents, such as those in an electronic conferencing system.In an electronic conferencing a system wherein data is shared between aplurality of participants during an electronic conference users, amethod is disclosed for maintaining consistency of the data among theparticipants during the electronic conference users. The In oneembodiment, the method of the present invention comprises the followingsteps: a) each participant in the electronic conferencing system usermaintains a local copy of the shared data for the electronic conferenceduring the electronic conference ; b) one of the participants userscommences to perform modifications to an associated local copy of theshared data; c) subsequent to the step of commencing modifications, aparticipant user requests an index for the modifications from anarbitrator participant user, wherein the modifications to the associatedlocal copy of the shared data may continue to be performed; d) thearbitrator participant user responds to the participant user requestingthe index for the modifications; and e) a participant user modifies theassociated local copy of the shared data according to the index receivedfrom the arbitrator participant user and then transmits the localmodifications to the plurality of participants users.

One of the objects of the present invention is to provide a dataconferencing system wherein real-time performance of individualparticipants in a data conferencing system do not suffer fromperformance problems due to medium throughput.

Another of the objects of the present invention is to provide animproved data conferencing system which enable users to have more orless real-time response from their individual systems in the conference.

Another of the objects of the present invention is to overcome the priorart disadvantages of the client/server model provided in certainconferencing applications.

Another of the objects of the present invention is to provide a systemwhich provides concurrency among a plurality of participants in aconferencing application, however, not having the attendantdisadvantages of real-time impacts upon performance due to such demandsof concurrency.

Another of the objects of the present invention is to provide thecapability to transfer very large pieces of data without impacting uponreal-time performance of users in a conferencing application program.

In one application, the users are participants of an electronicconference, and the shared data are the “meeting” data of the electronicconference.

Other objectsObjects, features and advantages of the present inventionwill be apparent from viewing the figures and the description whichfollows below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying in which like referencesindicate similar elements and in which:

FIG. 1a illustrates a topology of a system in which various agents maybe connected in an exemplary conferencing system.

FIG. 1b illustrates a block diagram of circuitry contained in one agentparticipating in a the exemplary conferencing system.

FIG. 2 illustrates a block diagram of the various control procedureswhich are present in an agent participating in an exemplary conference.

FIG. 3 illustrates a block diagram of classes used in one implementedembodiment of the present invention.

FIG. 4 illustrates the types of annotations which may be performed upona user interface display of a single agent within variousimplementations of the preferred embodiment.

FIG. 5 illustrates the object hierarchy used in certain embodiments ofthe present invention.

FIGS. 6a and 6b illustrate process-flow diagrams of a process performedupon detection of an event requiring the creation/deletion/modificationof objects during an exemplary electronic conference which may beexecuted from an event loop of the object manager in one embodiment ofthe present invention.

FIGS. 7a-7e illustrate object structures maintained by an arbitrator andan agent in an exemplary conferencing system during various time periodswhen an agent is performing actions in his local system.

FIG. 8 illustrates a method used for the deferred transfer of very largebinary object data within certain embodiments of the present invention.

FIG. 9 illustrates an object data request process flow diagram used inone embodiment of the present invention.

FIG. 10 illustrates the determination of a transport qualifier used fortransferring large object data in one embodiment of the presentinvention.

FIG. 11 illustrates a process flow diagram of a process used fordetermining the need for a partial request of large object data in oneembodiment of the present invention.

FIGS. 12a-12c illustrate various stages of completion of the transfer ofvery large object data in one embodiment of the present invention.

FIG. 13 illustrates the Background Transfer Manager architecture.

FIGS. 14-15 illustrate the processing logic for the ParticipantConnection/Disconnection Logic.

FIG. 16 illustrates a transfer queue entry.

FIG. 17 illustrates an example of the transfer request reprioritizationprocess.

FIG. 18 illustrates an example of the Clear-to-Send processing of atransfer queue entry.

FIGS. 19-20 illustrate the Request Processing Logic of the presentinvention.

DETAILED DESCRIPTION

The present invention relates to methods and apparatus for datacommunication between agents, such as those in an electronicconferencing system. Although present invention will be described withreference to electronic conferencing, including specific signal names,formats, time intervals and other specific information, these are to beviewed to be used for illustration purposes only and not to be construedas limiting the present invention. It can be appreciated by one skilledin the art that the present invention may be practiced in otherapplication areas, and many departures and modifications may be madewithout departing from the overall spirit and scope of the presentinvention.

As illustrated in FIG. 1a, a communication system may comprise aplurality of agents such as 11-14 which are all coupled to acommunication medium, e.g., 20 illustrated in FIG. 1a. In certainembodiments of the present invention, each individual agent coupled tothe medium 20 has equivalent capabilities to provide communicationbetween the agents. The For the illustrated exemplary system, theimplemented conferencing system uses a distributed approach wherein eachof the agents 11-14 maintains local copies of the conferencing structure(called a “meeting”) which shall be consistent with one another. Inaddition, one of the agents 13, in one embodiment of the presentinvention, acts as an arbitrator to grant requests to add objects tovarious structures within each agent to maintain consistency among thedisplayed objects on each of the agents' systems. The system used invarious embodiments of the present invention uses a distributedarchitecture, wherein each agent 11-14 maintains local copies of all theobjects being used in the electronic conference. Thus, displays, text,graphics and other information displayed on the agents' computer systemdisplays are represented in data structure maintained in each of thesystems' local memory and/or media devices coupled to those systems.Thus, the present system comprises a hybrid of the client/serverarchitecture wherein, instead of maintaining centralized copies of allthe objects, such as those in the electronic conferencing system, eachagent maintains a local copy of the data so that changes to the data maybe more or less immediate. The structure of one agent, which may becoupled to the communication medium such as 20 illustrated in FIG. 1a,is illustrated with reference to FIG. 1b.

Referring to FIG. 1b, a system upon which one embodiment of an agent(e.g., 11 of FIG. 1a) of the present invention is implemented in theexemplary application is shown as 100. 100 comprises a bus or othercommunication means 101 for communicating information, and a processingmeans 102 coupled with bus 101 for processing information. System 100further comprises a random access memory (RAM) or other volatile storagedevice 104 (referred to as main memory), coupled to bus 101 for storinginformation and instructions to be executed by processor 102. Mainmemory 104 also may be used for storing temporary variables or otherintermediate information during execution of instructions by processor102. System 100 also comprises a read only memory (ROM) and/or otherstatic storage device 106 coupled to bus 101 for storing staticinformation and instructions for processor 102, and a data storagedevice 107 such as a magnetic disk or optical disk and its correspondingdisk drive. Data storage device 107 is coupled to bus 101 for storinginformation and instructions. System 100 may further be coupled to adisplay device 121, such as a cathode ray tube (CRT) or liquid crystaldisplay (LCD) coupled to bus 101 for displaying information to acomputer user. An alphanumeric input device 122, including alphanumericand other keys, may also be coupled to bus 101 for communicatinginformation and command selections to processor 102. An additional userinput device is cursor control 123, such as a mouse, a trackball,stylus, or cursor direction keys, coupled to bus 101 for communicatingdirection information and command selections to processor 102, and forcontrolling cursor movement on display 121. Another device which may becoupled to bus 101 is hard copy device 124 which may be used forprinting instructions, data, or other information on a medium such aspaper, film, or similar types of media. In the described embodiments,another device which is coupled to bus 101 is a communication device 125which is used for communicating with other agents. This communicationdevice may include any of a number of commercially available networkingperipheral devices such as those used for coupling to an Ethernet orToken-Ring communication medium. Note, also, that any or all of thecomponents of system 100 and associated hardware may be used in variousembodiments, however, it can be appreciated that any configuration ofthe system may be used for various purposes according to the particularimplementation.

In one embodiment, system 100 is an IBM compatible type personalcomputer. Processor 102 may be one of the 80×86 compatiblemicroprocessors, such as the 80386, 80486 or Pentium TM brandmicroprocessor manufactured by Intel Corporation, Inc. of Santa Clara,Calif.

Note that the following discussion of various embodiments discussedherein will refer specifically to a series of routines which aregenerated in a high-level object-oriented programming language (e.g.,the Microsoft C/C++) available from Microsoft, Inc. Redmond, Wash. Thisseries of routines is compiled, linked, and then run as object code insystem 100 during run-time. It can be appreciated by one skilled in theart, however, that the following methods and apparatus may beimplemented in special purpose hardware devices, such as discrete logicdevices, large scale integrated circuits (LSI's), application-specificintegrated circuits (ASIC's), or other specialized hardware. Thedescription here has equal application to apparatus having similarfunction.

Software Organization of an Agent

Operative within each agent of the exemplary system during conferencerun time is a series of software procedures which are organized in themanner illustrated with reference to FIG. 2. FIG. 2 illustrates 200which is a general block diagram of the organization of the processeswithin a single agent in one embodiment of the present invention. Thesoftware organization 200 within a single agent comprises a multi-pointprocess 240 which is responsible for direct communication onto thecommunication medium 260 so that other agents 250 may be communicatedwith. This provides all the low-level communication functions whichallow direct accessing communication medium 260. In differentembodiments of the present invention, communication medium 260 may beany one of the various networking standards used including local areanetworks such as Ethernet, Token-Ring or other types of networkingstandards. Communication medium 260 may also be a telephone network andmodem connection or other data communications medium. Multi-pointfunction 240 thus provides all the necessary packetization and responsesto communication received over communication medium 260.

The next higher level in the software organization 200 of a single agentis the conference manager 230 which provides all the necessary executivefunctionality for communication with the low level communicationfunctions 240 and the higher level functions provided by the humaninterface process 210 and the object manager 220. The conference manager230 controls the object manager 220 through a series of callbacks tocommands in the conferencing system which are desired to be executed.Conference manager 230 also executes the callbacks in object manager 220according to messages which are received from the communication process240 and directs the creation, deletion or other action upon objects inthe system. As will be described in more detail below, objects withinthe system such as annotations, pages, commands and other objects usedwithin the system are treated using an object-oriented system whereinhierarchies of objects are defined. This will be described in moredetail below.

Communication from object manager 220 to conference manager 230 isprovided via messages which are passed to the multi-point link manager240 for the creation of objects, arbitration between the arbitrator andthe agent and communication with other agents in the conference.Moreover, conference manager 230 directs human interface process 210 viapointers to display various things on the display. Results from thedisplay of human interface functions are passed back to the conferencemanager 230 via messaging.

Object manager 220 is a process which is operative during run time tokeep track of the various objects used during a conference between theagent and other agents in the system. The object manager coordinates themeeting between the agents. The object manager keeps track of allobjects created during the meeting, including, other agents, the variousthings displayed during the conference and other objects. In addition,the object manager is used for maintaining the status of the meeting andkeeping all the other agents synchronized with the current agent.Contents of a meeting may be saved and retrieved from mass storage(e.g., 107 of FIG. 1b) when exiting or entering a conference. The objectmanager also exchanges meeting contents with other object managers inother agents to keep copies of the meeting synchronized.

Each object manager 220 maintains its own local copy of the meetingwhich is provided to human interface 210 as required. Object manager 220informs human interface 210 about changes from other agentsparticipating in the meeting. Human interface layer 210 then may adjustthe display as directed. Human interface 210 also informs the objectmanager about changes that the user wishes to make to the currentmeeting. Object manager 220 then synchronizes the changes with all otherobject managers participating in the meeting. The object managercontrols the human interface through messaging, as does the humaninterface direct the object manager to perform certain actions uponobjects, according to the adjustment of the display under control ofhuman interface 210. A brief overview of the structure of objects in oneembodiment of present invention is illustrated with reference to FIG. 3.

Object Classification Structure

FIG. 3 illustrates a general classification of the high level objectswhich are used in one embodiment of the present invention. In thisembodiment, the object manager class 300 comprises the broadestclassification of objects within the system. Generally, within theobject manager class, are two general areas, public meetings 310 andprivate meetings 320. The object manager maintains information that theuser has entered into his private space in the private meeting objectclass 320 which is distinct from the public meeting object class 310.Each is maintained as a separate structure of objects within the meetingclass. Therefore, during a public meeting stored in public meeting class310, a user may similarly store private information 320 also to beassociated with that same meeting.

In addition, object manager 220 maintains information about the user inclassification 330 and arbitrator 340, of which there is only one duringany one electronic conference and the other participants in the meetingin a participants classification 350. These are all also members of theobject manager class. Object manager 300 keeps track of the participantsin the meeting, such as when new participants join the meeting newparticipants' copies of the meeting are brought into synchronizationwith all of the other participants'. As participants leave the meeting,all of the users' contributions are ensured to be shared before theparticipant leaves the meeting.

One of the agents or participants in the meeting is known as thearbitrator. This is represented in the arbitrator class 340. Thearbitrator resolves conflicts between users when question of control ofmeeting properties arise. The arbitrator determines which participantcontrols an annotation, how many pages exist in the present meeting,etc. It also keeps a master copy of the meeting that all otherparticipants synchronize to. Object mangers within each agent orparticipant coordinate who the arbitrator is and assign a new arbitratorwhen the assigned arbitrator leaves the meeting or as dictated by otherconference events - such as opening/merging a meeting file in which theparticipant opening/merging the meeting file becomes the arbitratorprior to opening/merging the file. In one implementation of the presentinvention, the first user to start a meeting is assigned the arbitrator.

A very rough approximation of the types of objects which may be presentupon a participant's display is illustrated with reference to FIG. 4.Generally, a user will have a meeting area 400 on his display in whichvarious information may be entered. Typically, each meeting comprises aseries of pages which is analogous to a single white board or shareddisplay space which users in a room could access. Analogously, oneembodiment of the present invention uses the notebook metaphor which is,in fact, a shared “notebook” among a plurality of participants in themeeting into which every participant may enter information. The sharedarea or notebook comprises a plurality of pages 410 onto whichannotations may be made. Users may create or delete pages at will,subject to certain conditions. Annotations on the pages may comprise oneof at least four types, in one embodiment of the present invention. Thefirst three of these types are illustrated in FIG. 4. For instance, apage 410 may comprise a drawing annotation 411 which is typically anobject-oriented drawing created by a single user. Such object-orienteddrawing illustrations as 411 comprise a description of point positionsand segments between them and are well-known to those in the prior art.Annotations may also comprise graphic annotations 412 which aregenerally bit-map representations of graphic image data. Textualannotations 413 may be placed upon a page. Textual annotations can beany of the user's choosing and, including in certain prior artimplementations, allowing users to choose style, point size, font andother formatting information as is typical in the prior art. One otherannotation which may be used in one embodiment of the present inventionis the OLE annotation using the Object Linking and Embedding (OLE)protocol available from Microsoft Corporation of Redmond, Wash. OLEannotations may reference other “objects” created and/or maintained byother application programs and which may be either linked or embeddedusing OLE. Each of these annotations is stored as an object under an“annotation” classification which is associated with objects in the pageclassification. FIG. 5 illustrates the classification for objects usedin one embodiment of the present invention.

The overall structure of the object classes is illustrated withreference to FIG. 5. FIG. 5 includes the meeting object, user,arbitrator, participants and annotation objects which were discussed andillustrated with reference to FIGS. 3 and 4 above. In FIG. 5,relationships are illustrated with reference to the dotted line/solidbar representation wherein inheritance relationships are shown by thearrowhead with the direction of the inheritance following theorientation of the arrowhead. In addition, each of the relationshipsillustrated in the figures indicate multiple relationships. That is, ifa relationship is n:1 that means that there may be n of the sub-classobjects under the parent object. For example, as was illustrated anddiscussed with reference to FIG. 3 and now shown on FIG. 5, theCObjectManager 501 has two CCMeeting object classes: the “public”meeting and the “private” meeting shown in FIG. 3. In addition, theCCMeeting object class 506 has Participant objects 509 associated withit, those shown as 350 in FIG. 3. In addition, the CCMeeting objectclassification 506 references the CCPage object 508. The CCPageclassification is used for defining all the pages which may fall under aspecific meeting. Under the CCPage classification 508, are theannotation classifications (under the class CCAnnotation 532) which areshown with their various inheritance relationships in the lower sectionof the diagram. Thus, the CCAnnotation classification 532 may compriseobjects inheriting all relationships of the annotation object, for textannotations contained within the class CCTextAnnotation 521, theCCGraphicAnnotation 522 for representing graphic or bitmap annotationssuch as 412 in FIG. 4 and the CCDrawAnnotation class 523 for referencingdrawing annotations such as 411 shown in FIG. 4. One other annotationwhich may be used in one embodiment of the present invention is theCCOLEAnnotation class 520 which is part of the COLEDocumentclassification 503 for performing object linking and embedding using theObject Linking and Embedding (OLE) protocol available from MicrosoftCorporation of Redmond, Wash. Annotations may, thus, be references to“objects” created and/or maintained by other application programs andwhich may be either linked or embedded using OLE.

Other classifications are available from the Object Manager,classification 501 such as the CCPerson classification 512 which isassociated with a CCPassword classification 510 for associating userpasswords with person objects. Also, each person has an associatedCCAddress class 513 and a CCPhone class 514 for defining participantnetwork addresses and/or access telephone numbers.

Finally, the remaining set of object classes shown in FIG. 5 includesthe CCCachableBlob object classification 515 and the CCBlob class 516which has a relationship and inherits characteristics from theannotation object classification and the CCCachableBlob objectclassifications 532 and 515. The CCBlob 516 is used for representingvery large objects in various embodiments of the present invention.Various embodiments of the present invention allow very large binaryobjects, known in this embodiment as Binary Large Objects or BLOBs,which may be any type of data. These very large binary objects may alsobe shared and distributed among users. Further, various embodiments ofthe present invention allow for such objects to be transferred only upondemand of specific users and/or when medium traffic allows. In thismanner, the communication medium is not burdened with the task oftransmitting these very large binary objects, unless absolutelyrequired. Very large binary objects or BLOBs may be used forrepresenting any type of information, however, in certain embodimentsthey may only be used for representing large bitmap data or othergraphical image data such as compressed animations or audio informationsuch as those represented in MPEG (Motion Picture Experts Group)or JPEG(Joint Photographers Experts Group) format. It is anticipated inalternative embodiments that other binary data may be transmitted usingthese techniques, including executable program data.

Overview of Operation of Deferred Synchronization

As already has been discussed, each of the participants in an exemplaryconference maintains its own data regarding the current state of displayof the shared notebook for all users in the conference. In this manner,no individual participant is dependent upon the accessing of a centralserver for the display of its own information. However, a specialparticipant in the conference is known as the “arbitrator” and thearbitrator maintains an “official version” of a meeting. All otherparticipants are required to keep their versions synchronized with thearbitrator's official copy. A second participant may become anarbitrator either upon its own request or upon the arbitrator desiringto cease participating in the conference. In this case, all otherparticipants are also informed of the change and a new arbitrator canstart functioning. In one embodiment of the present invention, thearbitrator of a conference is the original participant that began themeeting.

The arbitrator also acts as a central system upon which annotations inthe official copy of the meeting structure are approved. Although usersmay make changes to their own local copies of the meeting structure inreal-time, without authority from the arbitrator, in order for themeeting to be maintained as consistent among all the participants, thearbitrator must make a final decision about the position of certainannotations. The allowing of a single participant to modify its meetingstructure without the authority of the arbitrator and the latersynchronization of that meeting structure with the other participants inthe conference will, for the remainder of this application, be referredto as deferred synchronization.

Associated with each page and annotation class object in the meetingstructure is a variable indicating whether the page or annotation hasbeen synchronized with other participants in the conference. This isknown as the “blocked” flag and this flag is set true until the page orannotation object has been synchronized with the other participants. Inaddition, the arbitrator maintains and grants object indices to newobjects as they are created and/or modified by a particular agent, thuskeeping the entire meeting synchronized among all the participants. Theagent then requesting the addition and/or modification of objectsreceives messages from the arbitrator indicating a new object index, sothat the participant may update his local meeting structure to complywith the remaining participants in the meeting. In addition, the blockedflag may then be changed to false indicating that the objects inquestion are now synchronized and no further communication needs to beperformed with the arbitrator for the present time.

For example, one participant may decide to add an annotation to anexisting page. Human Interface process 210 detects this request andsends a message to object manager 220 in order to add the annotation.Then a request is sent by the object manager 220 of the requestingparticipant to the object manger of the arbitrator. In addition, theobject manager will add an object to its local meeting structure withthe flag indicating that the annotation is “blocked” indicating that theobject has not been synchronized with other participants in the meeting.In addition, in the communication to the arbitrator, the participant hasindicated its participant index and a request for an object index fromthe arbitrator. Then the user of the agent may continue operation uponthe annotation, until the object index is received back from thearbitrator. Once the object index has been received, the participant mayupdate its meeting structure to comply with the index received back fromthe arbitrator. A more detailed discussion of this will be shown anddiscussed with reference to FIGS. 6a-7e.

Detail of Process for Deferred Synchronization

FIGS. 6a and 6b illustrate detailed process steps for a process 600which may be executed upon the detection of a request to execute acommand requiring synchronization with other participants in anexemplary meeting within the event loop of the exemplary conferencemanager. Thus, process 600 may be entered upon detection of a creationof a new object, modification of an existing object or the deletion ofan object as detected by human interface 210 on FIG. 2. Process 600 maystart at a typical process entry point such as 601 illustrated in FIG.6a. Then, it is determined whether the command is one which requiresdeferred arbitration at step 602. If not, then the current operation maybe performed with normal communication and the associated latency, ifany, between the current agent and any other participants in theconference at step 613. Then, at step 620, process 600 may exit at atypical process exit point.

If, however, it was a command which requires deferred arbitration, thatis, timing requirements for meeting synchronization are relaxed and theuser may make any modifications to the local meeting structure withoutthe latency incurred by synchronization with other agents and continuesat step 603. At step 603 it is determined whether the current commandhas occurred to change an object which is already “blocked”. An objectwill only be indicated as blocked if it has been determined that theobject was previously modified, deleted or added and the object has notyet been synchronized with other participants in the conference. Thisflag, as already discussed, is only set upon detection of a change, butprior to the assignment of an object index by the arbitrator. If it isnot blocked (e.g., this is an initial action upon the object), then atstep 604, it is determined whether the request has been detected for adeletion of the object. Deletion requires a specific series of steps,since ownership of all the objects requested to be deleted must beacquired prior to any deletion. This process also requires communicationwith other participants in the conference as shown on FIG. 6b. First, atstep 614, it is determined whether ownership of the object has beenobtained. This includes ownership of all the objects and sub-objects. Ifnot, then such ownership is requested from each of the owners of theobjects at step 615. If ownership is granted, as detected at step 616,or ownership of the object had already been obtained as detected at 614,then the process may continue back at step 605 illustrated on FIG. 6a.If not, then the delete failed as indicated at step 617, and the processreturns at a typical process exit point such as that shown as 620 inFIG. 6a.

At step 605 it has now been determined that the object is one which haspreviously not been blocked, that is, it has previously beensynchronized, and now some sort of change is occurring to the object.Thus, when this occurs, a request must be sent to request an objectindex for the object in order for the participant to be synchronizedwith all the other participants. However, the user may continue to makechanges and perform other operations even prior to the receipt of theobject index from the arbitrator. Thus, changes will therefore be localonly, until the later synchronization of the meeting structure of therequesting participant with other participants in the meeting. Therequested changes by the user are performed locally only at step 606,making all changes to the meeting structure which are permissible, andthe changes are indicated as blocked at step 607. Then, this sub-processwithin the event loop may be exited at step 620, a typical process exitpoint.

Process 600 continues through the initial steps, 601, 602 and 603 forblocked objects for which commands have been received. If the object isdetected as “blocked”, that is a request has been sent to the arbitratorfor an object index, however, no response has yet been received theprocess 600 continues at step 609. Step 609 detects whether the responsecontaining the object index has been received from the arbitrator. Ifnot, then the process proceeds to steps 606, 607 and 620, as alreadydiscussed. That is, changes continue to be performed locally and anychanges are indicated as blocked until the synchronization with thearbitrator and, thus, the other participants has occurred.

If, however, a response has been received from the arbitrator, then theobject index is received at step 610. Then, the participant may updateits local meeting structure at step 611 in order to make the participantsynchronous with the arbitrator (and thus the other participants in themeeting). In addition, the Human Interface HI layer 210 is informed ofthis occurrence in order for the participant to update its display. Forexample, if a page had been added by the participant which the localparticipant assigned page 4, but the arbitrator now assigns to page 5,the human interface layer 210 detects this change and updates thedisplay accordingly to move the page visually to page 5. For example, inthe notebook metaphor shown on the display, a new page “tab” may becreated for the page using well-known prior art user-interface commandsto associate a new page tab labeled “Page 5” with the locally createdpage. Then, after its own local meeting structure and display have beenmodified at step 611, the participant broadcasts any of the blockedchanges, that is changed pages or annotations, to the other participantsin the conference at step 612 as requested by the participants.Therefore, none of the other participants is synchronous with thecurrent participant until this time. Once this is accomplished, theother participants in the conference may also update their own localmeeting structures and associated displays with the appropriate pagesand annotations in order to be synchronous with the participantperforming the change. Finally, the current operation then may beperformed with normal communication at step 613, thus making all theparticipants synchronous in the conference. Then, at step 620, theprocess exits at a typical process exit point.

A simple illustration of an exemplary local and an exemplaryarbitrator's meeting structures may be illustrate with reference toFIGS. 7a-7e, showing the addition of an object during certain steps inthe process 600 illustrated in FIGS. 6a-6b. For example, at a timeperiod t₁ as illustrated in FIG. 7a, a single agent or participant mayhave three items in its meeting structure 701-703, linked in ahierarchical fashion, e.g., a list of annotations or a list of pages.Similarly, an arbitrator agent may also have a similar three objects inits meeting structure, 711-713, wherein all the objects are not blockedin either agent. At a second time period t₂, as illustrated in FIG. 7b,the participant may create an additional object (e.g., 704), such as apage or an annotation to add to its local meeting structure.Simultaneously, the arbitrator may receive a request from a secondparticipant to add an object to its meeting structure O′₄ 714 due to arequest to add command. Then, subsequently, at time t₃, the arbitratorand the agent will each have within its local meeting structure, adifferent object having the same object index 4. For example, the agentmay have the object 704 as its fourth object in its object meetingstructure and the arbitrator may have object 714 as its fourth object inits meeting structure. Then, at a subsequent time period t₄, the agentwill send a request to the arbitrator requesting the adding of anadditional object to the “official” object structure maintained by thearbitrator. This is illustrated as 715 in FIG. 7d. Because all requestsare serialized at the arbitrator from each of the participants in theconference, the request from the first agent to add the object 715 hasarrived later in time than that request for the object 714. Thus, it isassigned an object index 5. The arbitrator will then transmit back tothe requesting agent the index 5 to be associated with the object. Thearbitrator then transmits back a response indicating that the object 704should instead be assigned the object index 5. Another participant thentransmits back a new object to be inserted into the local participant'sobject list O′₄ 705. Thus, at a subsequent time interval t₅ illustratedin FIG. 7e, both the arbitrator's and the original agent's meetingstructures may be fully synchronized with one another and otherparticipants in the conference. That is, all objects in the agent'smeeting structure and the arbitrator's meeting structure are the sameand in the same order.

Therefore, deferred synchronization of objects for participants in anelectronic conference poses substantial advantages over theclient/server model of the prior art; because, timing requirementsbetween the client and server are more relaxed. Because full consistencybetween participants is deferred, local participants may perform suchCPU-intensive operations as the modification and creation of annotationsin real-time without the latency in coordinating such operations withthe server. A further advantage which deferred synchronization ofobjects has over the client/server model of the prior art is that thesynchronization of objects for all participants is provided withoutusing a central data repository as common in the client/server model.This is substantial advantage because the computer conferencing systemcan be used between personal computers where a network client/servermodel is not available or practical. The local participant will performall such changes to its local display and meeting structure, and updateswill only be coordinated upon the receipt of a response from thearbitrator assigning an object index. Therefore, the present inventionposes substantial advantages over the prior art systems which requirefull synchronization at all times between all participants in theconference thus incurring substantial latency for synchronization andresponse delays in the user's interface to the system.

Transfer of Large Object Data

One of the types of object data which may be transferred between users,such as participants in an electronic conference is known as a veryBinary Large OBject or “BLOB.” A BLOB is an object which would notnormally be able to be transmitted during one complete idle cycle of theparticipant and transport medium. Thus, such objects need to be brokeninto smaller portions, or packets and transmitted over several idlecycles by a background task. BLOB's typically comprise items such asvery large graphic data, OLE annotations or files to be transferred. Inother embodiments of the present invention, such BLOB's may includefull-motion video objects such as MPEG or JPEG files and/or audio data.Using the methods and apparatus described, the BLOB data is transmittedin packets, the size of each of the packets being dynamically based uponthe capabilities of the transport medium, which may dynamically changeas the connection between participants change. Therefore, if the speedof the connection between two participants' transport medium changes,the size of packets transmitted by the transmitter is changed. This isdone dynamically during transmission time, in order to allow the mostefficient use of the transport medium during the transmission of BLOB's.In addition, BLOB transmit requests are queued so that higher-priorityBLOB's may be transmitted before lower-priority BLOB's. In this way, aparticipant who is viewing a first page containing BLOB data whoswitches pages to a second page also containing BLOB data, the secondpage, which becomes the current viewing page containing the BLOB(s),becomes reprioritized within the transmitter to be transmitted ahead ofthe BLOB for the first page. This is done using a reprioritizationrequest from the requester. Then, the out-going transfer queue isre-arranged by the transmitter to effect the desired change of transferpriority. The details of these mechanisms will now be discussed.

First, during a typical an exemplary electronic conference, BLOB datamay not necessarily be transmitted to other participants upon creationof a BLOB within a local participant. In other words, transmission ofthe data for a BLOB may be deferred until a later time at which thetransport medium may be idle, or the local participant has some idleprocessing time. Therefore, during creation of a BLOB, remoteparticipants may be notified that the BLOB data is not contained withinthe BLOB to be created, and the remote participant(s) only create theobject in their local meeting structures for the BLOB absent any data.During later idle periods of either the local participant and/or theremote participants, the BLOB data itself to be contained within theBLOB object in the meeting structure of the remote participants, may beadded at such time as is convenient for the two participants. A typicalchronology of actions which may be performed during a BLOB creation andtransmission is illustrated with reference to FIG. 8.

The steps illustrated with reference to FIG. 8 illustrate the sequenceof steps taken by exemplary local and an exemplary remote participant(s)engaged in a conference. For example, at a first step such as 801 inFIG. 8, a local participant may add to its local meeting structure anobject containing a BLOB. The object manager 230 contained within thelocal participant will then notify all the remote participants that theyshould also create objects within their local meeting structures anobject for a BLOB, at step 802. This, of course, is performed after allnecessary synchronization, as was described with reference to thedeferred synchronization process above, including determination of theobject index and other relevant information for an object. Then, each ofthe remote participants individually submits asynchronous requests atstep 803 to the local participant for the BLOB data. The localparticipant then, at step 805, processes the request for BLOB data suchas placing the request in a BLOB request queue and later providing thedata during idle times. Also, subsequent to the asynchronous requests byvarious participants for the BLOB data at step 803, the remoteparticipants may further submit reprioritizations of prior requests forBLOB data at step 804. In other words, if a remote participant had firstrequested BLOB 1 and then later subsequently requested BLOB 2, the tworequests may be reprioritized so that BLOB 2 may take priority over BLOB1 for the remote participant. In this manner, if the remote participantswitches from a first page containing BLOB 1 to a second page containingBLOB 2, the local participant will then re-order the BLOB requests forthat particular participant.

As already discussed, the exemplary local participant processes requestsfor the BLOB data at step 805. This will be discussed in more detailwith reference to FIG. 9 below. The local participant then sends to eachof the remote participants the requested BLOB data packets at step 806.As will be discussed in more detail below, BLOB data packets are sentaccording to the transport medium between the two participants.Therefore, if the remote participant is connected to a high-capacity,high-speed transport medium such as a Ethernet, then the size of thedata packets will be substantially larger than if the participant wasconnected via modem over a telephone line. As the local participantsends the BLOB data packets at step 806, each of the remote participantsreceives the BLOB data and adds the BLOB data packets to the existingBLOB data structure. Then, the local participant after completion of thetransmission of all the BLOB data packets for the requested BLOB,removes the BLOB from the request queue upon completion of the datatransfer at step 807. The human interface process of the remoteparticipant is notified to update the display of the previouslyincomplete BLOB-containing object. More detailed illustrations ofcertain of the process steps will now be discussed.

Process 900 of FIG. 9 illustrates a series of steps which are taken byan exemplary local participant upon receipt of a request for BLOB data,the request being transmitted by exemplary remote participants. Forexample, at step 901, a process entry point such as that from an eventloop of a main process is entered. That is, multiple new andreprioritization requests may be received from multiple participantsasynchronously. Then, at step 902, the transport qualifier for the newrequest or for a reprioritization request is determined. That is, it isdetermined whether the transport medium for the remote participant iseither a high or low-speed transport medium. Determination of the mediumcapability (i.e., high or low-speed) is used as a qualification whenconsidering the combination of requests from multiple participants. Aswill be discussed in more detail below, during transfer of a BLOB, foreach BLOB in the transfer queue, a SIZE and an OFFSET is maintained foreach transfer queue entry of BLOB data so that the last datum in theBLOB which was transferred may be referenced. Multiple requests can becombined into one queue entry, and likewise, multiple reprioritizationrequests simply reprioritize queue entries. Therefore, upon an initialrequest for BLOB data, the offset will be zero, that is, the beginningof the BLOB, and the size will be set equal to the full length of theBLOB. At any rate, more detailed steps for determining the transportqualifier will be illustrated with reference to process 1000 of FIG. 10.An example of the reprioritization process is described in connectionwith FIG. 17.

Once the transport qualifier has been determined, it is determined atstep 903 whether an existing request for data pending indicates receiptof a reprioritization request of an original request for BLOB data. Ifit is a request for pending data, then it is determined at step 904whether a partial request is required. That is, if other remoteparticipants request the same BLOB data which has already been requestedand which has already started to be transferred, the new requestingparticipants may receive the BLOB data from the intermediate point atwhich the request was made, but they will also require any data whichhad been transferred up until that point. Thus, redundant transfers ofdata are eliminated by combining nearly simultaneous requests frommultiple remote participants. For cases where transfer associated withan original request has not yet started, the subsequent requestingparticipants are merely added to the distribution list of the originaltransfer queue entry. Otherwise, if transfer has commenced, in additionto the above, one additional transfer queue entry will be added toaccount for the data already transferred. If, however, no pendingrequests exist for the actual BLOB data, then a new transfer queue entryin entered into the participant's transfer queue at step 905, in orderto keep track of the BLOB transfer. As previously discussed, the queueentry maintains an OFFSET and SIZE in order to track the transfer forindividual requests. At any rate, upon completion of either steps 904 or905, the data request processing is complete at step 906, after which anactual data BLOB transfer will occur in the background (i.e., duringidle processing time), and the process 900 will return to the normalevent loop of the executive routine of the local participant.

A more detailed illustration of the process steps taken at step 902 ofFIG. 9 is illustrated with reference to FIG. 10. Process 1000 is usedfor determining the transport qualifier. The transport qualifier is usedin handling the combination of multiple requests. That is, requests fromrecipients connected via a high-speed medium are not combined withrequests from recipients connected via low-speed media, and viceversa.). This is done dynamically, upon each request for transfer of aBLOB packet during idle processing time. Thus, the transport qualifierfor a particular participant is used to allow the higher orlower-capacity transport medium to be accommodated. Note that thetransport qualifier may specify any number of levels of transportthroughput. The present invention is not limited to a high and low levelonly. For example, the transport levels can be specified to partition4800 band modems, 9600 band modems, ISDN connections, fast and slownetwork connections, etc.

At any rate, process 1000 starts at a typical process entry point 1001.Then, at step 1002 it is determined whether a high-speed transportfacility is available between the local and requesting participant. Ifso, then the high-speed transport qualifier is used at step 1003. If,however, the remote and local participants are coupled via a low-speedtransport medium as detected at step 1002, then at step 1004, alow-speed transport qualifier is used. At any rate, at step 1005,determination of the transport qualifier is complete and theaccompanying process may continue.

The deferred transfer of object data process which was discussed withreference to step 904 of FIG. 9, is now discussed with reference toprocess 1100 of FIG. 11. For example, it has already been determinedthat an existing request is pending for the specific BLOB data at step1101, a typical process entry point from an event loop of an executiveprocess. If a request is already pending for the current participant atstep 1102, then it is considered a reprioritization request for thegiven participant and the existing BLOB request on the transfer queue isreprioritized at step 1107 illustrated in FIG. 11. Thus, any other BLOBrequests for that particular participant are reprioritized. Then, atstep 1106, the process is complete and process 1100 is returned from ata typical process exit point.

If, however, a request was not pending for this particular participant,as detected by referencing the participant index for the requestingparticipant which is associated with the element in the transfer queue,then, at step 1103, the requesting participant is added to thedistribution list for the existing transfer queue entry. Therefore, theparticipant index may be added to the existing transfer queue entry. Acorresponding partial request entry may exist for each participant inthe distribution list, but it is not required. Requests from multipleparticipants may have been received prior to commencing associated datatransfer and as such only the single transfer queue entry exists. Oncedata transfer commences, additional requests from new participants willcause a combining with the existing entry and the addition of a partialentry for the data transfer completed at that time. Therefore, if datatransfer has already commenced for the particular BLOB as specified inits transfer queue entry at step 1104, then a partial request for theremaining portion of the BLOB must be added into the transfer queueentry. This is performed at step 1105. That is, all the data associatedwith the BLOB and previously transferred to the other remoteparticipants must be transferred to the current requesting participantupon completion of the current transfer. This is so that thisparticipant may also bring its BLOB current with the other participants'in the conference. If, however, data transfer has not been commenced forthis entry, the requesting participant has merely been added to theexisting transfer queue entry at step 1103 and step 1104 proceeds tostep 1106, the process exit point. The partial request for the portionof an existing transfer entry previously transferred at step 1105 willbe illustrated in more detail with reference to FIG. 12. Thus, anadditional partial request is added to the transfer queue at step 1105.This will now be discussed with reference to FIG. 12.

The preparation of partial requests will be illustrated with referenceto FIGS. 12a-12c. For example, a BLOB of 38,000 bytes may be requestedby two participants B and C to be transferred from a local participant.In this case, initially, the offset will be set to zero for the twoparticipants and in a remaining transfer will be equal to 38,000. Then,at some intermediate time period later, e.g., time t₁ (time after datatransfer has commenced) illustrated in FIG. 12a, the transfer offsetwill be equal to 2000, and the remaining transfer size will be equal to36,000 indicating that 2000 bytes have been transferred to date. This isillustrated with reference to portion 1201 and portion 1202 of thegraphic representation of the BLOB 1200. At this time period, then athird participant, participant D, may request transfer of the same BLOBdata from the local participant. In this case, participant D is added tothe distribution list (of the existing BLOB queue entry with OFFSET 2000and SIZE 36000) and a subsequent partial (request) transfer queue itemwill be added to the transfer queue at a position after the currenttransfer queue entry (for OFFSET 0 and SIZE 2000). Thus, at a subsequenttime period t₂ illustrated in FIG. 12b, participant D will be added tothe existing transfer entry distribution list and transfer may continuefrom the transfer offset 2,00 and the remaining transfer size 36,000indicated in the BLOB transfer queue entry. This is graphicallyrepresented with reference to 1210 which illustrates the to-date portiontransfer 1211 and the remaining portion 1212. Finally, upon completionof the transfer of the item represented in FIG. 12b, another queue entrywill be referenced for transferring only a portion of the BLOB sinceparticipant D's request was received in the middle of the initialtransfer to participants B and C. In this instance, the next transferentry at time t₃ illustrated in FIG. 12c, will have a transfer offset ofzero (indicating the beginning of the file) and a remaining transfersize of 2000 indicating that the first 2000 bytes of the BLOB arerequested to be transferred to participant D. This is illustratedgraphically with reference to 1220 illustrating the complete BLOB andonly the portion 1221 which is requested by this queue entry to betransferred to participant D. Once this partial transfer has beencompleted, then all of participants B, C and D have received thecomplete BLOB and redundant transfers of the portion of the datarepresented by 1202 and 1212 and FIGS. 12a and 12b have been avoided.Thus, participant D only receives the portion which was transferred upuntil the time in which its own request was made, that is represented byarea 1221 in FIG. 12c. The transfer of data for the partial portionillustrated in FIG. 12c is transferred from the end of the partialportion to the beginning, in order so that the BLOB may be maintainedcontiguously in the memory of the requesting participant. Then, uponcompletion of receipt of the partial portion illustrated in FIG. 12c,the participant D notifies its human interface to update the display ofthe annotation containing the previously incomplete BLOB object. Thus,upon completion of the transfer indicated by the transfer entry shown inFIG. 12c, the transfer of the BLOB to all of participants B, C and D iscomplete. Transfer to participant B and C is complete after completionof the transfer associated with the original queue entry. Transfer toparticipant D completes at a later time when the queue entry associatedwith the partial request is complete.

During transfers of such BLOB data, the exemplary remote participant andthe exemplary local participant may be informed of such operations usinga progress bar or other user interface feature under control of theHuman Interface (HI) layer 210 of the agent during participant idletime. Thus, the user may be informed of intermediate transfers of datafor proper system feedback.

Note that the BLOB data transfer mechanism uses a Clear-To-Send or CTSprotocol wherein if transfer of data associated with a particulartransfer queue entry cannot continue because a recipient is notClear-To-Send, subsequent transfer queue entries not containing a notClear-To-Send recipient are considered for transfer. This is performedin order to maximize full potential of the transport medium, during idletimes of individual participants. The Clear-to-Send protocol of thepresent invention is described in more detail in connection with FIG.18.

Referring now to FIG. 13, an architectural diagram illustrates thecomponents of the Background Transfer Manager (BTM) of the presentinvention. The transfer of large object data is controlled by the BTM.The BTM consists of six major portions: 1) user/participantconnection/disconnection control logic 1312, 2) request processing logic1314, 3) data transfer processing logic 1316, 4) a Clear-To-Send list1318, 5) an out-going transfer list 1320, and 6) an in-coming transferlist 1322. The logic component 1312 is described in connection withFIGS. 14 and 15. The logic components 1314 and 1316 are described inconnection with FIGS. 16-20. The Clear-To-Send list 1318 is used tomaintain the Clear-To-Send status of requests. This protocol isdescribed in connection with FIG. 18. The in-coming transfer list 1322is used to record those entries for which BLOB data requests have beensubmitted to remote users. The BTM uses this list when processingsubsequent requests to determine whether to send a new request or areprioritization request. The out-going transfer list 1320 is used tomaintain priorities of out-going BLOB data transfers.

PUser/participant connection/disconnection processing logic 1312pertains to re-initialization upon notification of participantconnection and flushing of participant-specific information uponparticipant disconnect notification. Referring now to FIGS. 14 and 15,flowcharts illustrate this connection and disconnection processing.

Referring to FIG. 14, a notification of an exemplary participantconnection is received at block 1410. The newly connected participant isadded to the Clear-To-Send list 1318 at block 1420. Depending on thetransport medium characteristics, the participant is qualified for highspeed transfer with a corresponding optimal packet size (blocks 1428 and1430) or qualified for low speed transfer with a corresponding optimalpacket size (blocks 1434 and 1436).

Referring to FIG. 15, a notification of an exemplary participantdisconnection is received at block 1510. The optimal packet size isrecalculated in block 1520. The participant is removed from theClear-To-Send list in block 1522. The participant is removed from alldistribution lists for all transfer queue entries in block 1524.Transfer queue entries for which the participant was the only recipientare removed in block 1526.

At the time of participant connection/disconnection, optimal transfersizes are determined for each level of transport throughput (high andlow-speed) in use. These sizes remain constant between participantconnection and disconnection events. Or put another way, onlyparticipant connection and disconnection events affect the optimaltransfer size. Note that the optimal transfer size is not a maximumtransferable packet size. It's the most optimal size that can be handledto prevent partitioning of the packet. Utilizing this packet size, orsmaller, the packet takes the fastest path through the processing logicon both the send and receive ends.

Referring again to FIG. 13, Request Processing logic 1314 is used onboth sending and receiving systems. The Request Processing logic 1314and Data Transfer logic 1316 both use a transfer queue for tracking thestatus of BLOB requests and BLOB data. Referring to FIG. 16, anarchitectural diagram illustrates the structure of a single BackgroundTransfer Manager Transfer Queue entry 1610. The transfer queue entry1610 comprises a reference to a single BLOB object 1612 that representsthe BLOB object being tracked by the transfer queue entry. A nexttransfer offset 1614 and a remaining transfer size 1616 is used to trackthe progress of the transfer of BLOB data. Recipient list 1618 is a listof participants that should receive the particular BLOB identified byreference 1612. Previous transfer queue entry 1620 and next transferqueue entry 1622 are used to link BLOB requests together in the transferqueue.

Referring to FIG. 19, the Request Processing logic 1910 for a requestingparticipant is illustrated. FIG. 20 illustrates the Request Processinglogic 2010 for a BLOB originator. A BLOB originator of BLOB data sends aBLOB object structure without its corresponding data to otherparticipants. These other participants are referred to as “requestors”relative to this BLOB data. As shown in FIG. 19, a requestor of BLOBdata first checks the in-coming transfer list 1322 to determine if aparticular BLOB is already in the list 1322 (decision block 1912). Ifso, a reprioritization request is sent to the BLOB originator therebyincreasing the priority of the existing request for BLOB data(processing block 1922). If the BLOB is not already in the in-comingtransfer list 1322, the BLOB requestor adds a transfer queue entry tothe in-coming transfer list 1322 (processing block 1918) and sends a newrequest for BLOB data to the BLOB originator (processing block 1920).Request Processing logic for a BLOB requestor then terminates throughreturn bubble 1924.

As shown in FIG. 20, the BLOB originator then processes this request andeither adds a new out-going transfer queue entry (processing block2018), reprioritizes an existing transfer queue entry (processing block2026), or combines the request with an existing entry (processing block2034) to track the transfer of the BLOB data. No BLOB data transferoccurs as a result of this processing.

FIG. 17 illustrates an example of transfer queue reprioritization. Asshown, BLOB requests are added to the transfer queue in the orderreceived (step 1720 and 1730) until a reprioritization request isreceived (step 1740). At step 1740, request 1 is moved ahead of request2. Subsequent requests are added to the transfer queue (step 1750) untilanother reprioritization request is received (step 1760). In this case,request 3 is moved ahead of both request 1 and 2. If anotherreprioritization request is received, the subject request (request 1 instep 1770) is moved ahead of the other requests in the transfer queue.

Referring again to FIG. 13, Data Transfer processing logic 1316 is usedduring processing idle time. At this time, the BTM examines the currentout-going transfer queue for entries requiring data transfer. For theseentries, the BTM repeatedly checks if the transport is Clear-To-Send apacket of optimal size (as previously determined) to the list ofrecipients listed in the transfer queue entry, and sends the packet ifClear-To-Send. The Clear-To-Send list 1318 is used to track theClear-To-Send status of packets of BLOB data. If not Clear-To-Send, therecipients are marked as not Clear-To-Send, and the BTM proceeds to thenext transfer queue entry whose recipient list does not contain a notClear-To-Send recipient and repeats the packet sending process. Thisprocess continues until either all BTM entries have been processed orall participants are marked as not Clear-To-Send. At this point, allparticipants' not Clear-To-Send status is cleared to prepare for thenext idle time processing.

FIG. 18 illustrates an example of the Clear-To-Send processing of thepresent invention. In this example, each cell or box represents atransfer queue entry. The numeral in each cell represents an entrynumber used solely for identification purposes. The letter(s) in eachcell represent(s) the recipient(s) corresponding to the transfer queueentry. In the initial state in this example (step 1810), each transferqueue entry (cell) is initialized and each recipient is initiallyClear-To-Send (A-OK, B-OK, and C-OK). In step 1820, packets from entry 1are sent until recipient B is no longer Clear-To-Send (i.e., NotClear-To-Send—NCTS). In this case, the Data transfer processing logic1316 shifts the data transfer operation to entry 2 (step 1830). In step1830, packets from entry 2 are sent until recipient C is no longerClear-To-Send. In step 1840, entry 3 is skipped, because participant B,which is a recipient of entry 3, is Not Clear-To-Send. In step 1850,packets from entry 4 are sent until recipient A is no longerClear-To-Send. Because all entries in the transfer queue are notClear-To-Send in step 1860, data transfer processing ends and processingreturns to the main loop. This process is repeated during each idletime.

Thus, in conclusion, an improved method for the transmission of verylarge object data and the deferred synchronization of user data, such asparticipants data maintained during an electronic conference has beendescribed. Although the present invention has been described withreference to specific application and embodiments, it can be appreciatedby one skilled in the art that may the present invention may bepracticed in other data sharing applications, and departures and as wellas modifications may be made, and the present invention is only to beconstrued as limited by the appended claims which follow.

What is claimed is:
 1. In an electronic conferencing system wherein datais shared between a plurality of participants during an electronicconference, a method of maintaining consistency of shared data amongsaid participants during said electronic conference comprising thefollowing steps: a. each participant of said plurality of participantsin said electronic conferencing system maintaining a local copy of saidshared data for said electronic conference during said electronicconference; b. one participant of said participants commencing toperform modifications to an associated local copy of said shared data;c. subsequent to commencing modifications, said one participantrequesting an index for said modifications from an arbitratorparticipant, wherein said modifications to said associated local copy ofsaid shared data may continue to be performed; d. said arbitratorparticipant responding to said one participant with said index for saidmodifications to said associated local copy of said shared data; e. saidone participant of said participants modifying said associated localcopy of said shared data according to said index received from saidarbitrator participant; and f. transferring said modifications of stepsb through e above to a remote participant.
 2. The method as claimed inclaim 1 wherein said shared data further includes an object.
 3. Themethod as claimed in claim 2 further including a step of determiningwhether ownership of said object has been obtained.
 4. The method asclaimed in claim 2 further including a step of determining whether saidobject is blocked.
 5. The method as claimed in claim 2 further includinga step of deleting said object.
 6. In an electronic conferencing systemwherein data is shared between a plurality of participants during anelectronic conference, an apparatus for maintaining consistency of saiddata among said participants during said electronic conferencecomprising: a. means for maintaining a local copy of said shared datafor said electronic conference during said electronic conference, eachparticipant of said plurality of participants in said electronicconferencing system including said means for maintaining; b. means forcommencing to perform modifications to an associated local copy of saidshared data; c. means for requesting an index for said modificationsfrom an arbitrator participant, wherein said modifications to saidassociated local copy of said shared data may continue to be performed,one participant of said participants including said means forrequesting; d. means for responding to said one participant with saidindex for said modifications to said associated local copy of saidshared data, said arbitrator participant including said means forresponding; e. means for modifying said associated local copy of saidshared data according to said index received from said arbitratorparticipant; and f. means for transferring said local modifications to aremote participant.
 7. The apparatus as claimed in claim 6 wherein saidshared data further includes an object.
 8. The apparatus as claimed inclaim 7 further including a means for determining whether ownership ofsaid object has been obtained.
 9. The apparatus as claimed in claim 7further including a means for determining whether said object isblocked.
 10. The apparatus as claimed in claim 7 further including ameans for deleting said object.
 11. In an electronic conferencing systemwherein data is shared between a plurality of participants during anelectronic conference, an apparatus for maintaining consistency of saiddata among said participants during said electronic conferencecomprising: a. maintenance logic associated with each of theparticipants that correspondingly maintains for the participants localcopies of said shared data of said electronic conference during saidelectronic conference; b. modification logic associated with each of theparticipants for making modifications to the corresponding local copiesof said shared data; c. request logic associated with each of theparticipants that correspondingly request indices for the modificationsbeing made by the participants to their local copies of said shareddata, upon commencement of the modifications; d. respond logicassociated with at least one of the participants that responds to eachof said participant indices requests, said modification logic furthermodifying the local copies of the shared data according to saidrequested indices upon received them; and e. transfer logic associatedwith each of the participants that transfers said modifications to otherremote participants upon completing said modifications to the localcopies in accordance with the received indices.
 12. The apparatus asclaimed in claim 11 wherein said shared data further includes an object.13. The apparatus as claimed in claim 12 further including determinationlogic associated with each of the participants that determines whetherownership of said object has been obtained.
 14. The apparatus as claimedin claim 12 further including determination logic associated with eachof the participants that determines whether said object is pendingsynchronization.
 15. The apparatus as claimed in claim 12 furtherincluding deletion logic that deletes said object.
 16. An apparatusequipped with: a. modification logic for modifying a local copy ofshared data that is to be synchronized with corresponding remote copies;and b. requesting logic that requests for an index for a modificationfrom an external source, upon commencement of said modification, saidmodification logic further modifying said associated local copy of saidshared data according to said requested index, upon receiving saidrequested index.
 17. The apparatus as claimed in claim 16 wherein saidshared data further includes an object.
 18. The apparatus as claimed inclaim 17 further including determination logic that determines whetherownership of said object has been obtained.
 19. The apparatus as claimedin claim 17 further including determination logic that determineswhether said object is pending synchronization.
 20. The apparatus asclaimed in claim 17 further including deletion logic that deletes saidobject.
 21. The apparatus as claimed in claim 16 wherein said apparatusfurther comprising: e. responding logic that responds to the request forthe index to modification being commenced against one of said remotecopies of said shared data, the local copy of shared data being a mastercopy of the shared data.
 22. The apparatus as claimed in claim 16wherein said apparatus further comprising: e. transfer logic thattransfers said local modifications to a remote user having acorresponding remote copy of shared data to be synchronized to themodified local copy of shared data.
 23. The apparatus as claimed inclaim 16 wherein said apparatus is an electronic conferencing system.24. In a digital system wherein a local copy of shared data ismaintained, a method for synchronizing the local copy of the shared datato corresponding remote copies of the shared data, the method comprisingthe steps of: a. upon commencing making modification to said local copyof shared data, requesting an index for said modification; b. uponrequesting the index, continuing to modify said local copy of shareddata; c. receiving said requested index; d. modifying said local copy ofshared data according to said received index.
 25. The method as claimedin claim 24 wherein said method further comprises the step of: e.responding to a request for an index for modifications being made to acorresponding remote copy of shared data, the local copy of shared databeing a master copy of the shared data.
 26. The method as claimed inclaim 24 wherein said method further comprises the step of e.transferring said modifications to said local copy of shared data to aremote user having a corresponding remote copy of shared data to besynchronized with the modified local copy.